1. Field of the Invention
Embodiments according to the invention relate to a method and apparatus for frame redirection in a Storage Area Network (SAN) environment. More particularly, embodiments according to the invention relate to frame redirection, which includes methods to intercept and re-route traffic between an initiator and a target.
This application is related to U.S. patent application Ser. No. 10/695,408, the contents of which are incorporated by reference.
2. Description of the Related Art
Effectively deploying multiple devices in a network environment becomes an increasingly complex task as transmission data rates, processor speeds, and storage capacities increase. Storage area networks (SANs) have been developed as specialized high-speed networks, referred to as fabrics, to connect computer systems, control software, and storage devices over the fabric. A SAN typically allows block level input/output (I/O) rather than file-level access. Thus, every device connected to a SAN fabric appears as a locally attached device to other devices on the fabric.
FIG. 1A shows components in a fabric 102. The fabric 102 includes a host 104, a Fibre Channel switch 107, and one or more storage devices 120a, 120b. Each host 104 and storage device 120 may be one of a number of specific devices. The host 104 may be, for example, a server, while the storage devices 120a, 120b may be RAID devices, which in turn may be logically separated into logical units. Alternatively the storage devices 120a, 120b could be a JBOD (“just a bunch of disks”) device, with each individual disk being a logical unit.
A SAN allows for relatively simple interchangeability of components with minimal disruptions to other components, as discussed above. However, as the size of a SAN increases (and correspondingly, storage needs on the SAN increase), it becomes beneficial to merge resources such as storage devices 120a, 120b into single logical devices, making it easier for hosts 104 to access the storage devices 120a, 120b. One such method of merging resources is addressed through virtualization. In general terms, virtualization is a process used to collect storage resources into a pool and hand out logical slices to hosts, without any reconfiguration on the host side or on the storage side. Then, through modifications to the host 104, switch 107, or storage devices 120a, 120b (or some combination thereof), traffic intended to pass from an initiator (e.g., host 104) to a target (e.g., storage device 120a) is re-routed to a “virtual” target and on to the defined physical target or targets.
Storage virtualization provides to computer systems a separate, independent view of storage from the actual physical storage. A computer system (e.g., a host) sees a virtual disk. As far as the host is concerned, this virtual disk appears to be an ordinary SCSI disk logical unit. However, this virtual disk does not exist in any physical sense as a real disk drive or as a logical unit presented by an array controller. Instead, the storage for the virtual disk is taken from portions of one or more logical units available for virtualization (the storage pool). This separation of the hosts' view of disks from the physical storage allows the host's view and the physical storage components to be managed independently from each other. For example, from the host perspective, a virtual disk's size can be changed (assuming the host supports this change), its redundancy (RAID) attributes can be changed, and the physical logical units that store the virtual disk's data can be changed, without the need to manage any physical components. These changes can be made while the virtual disk is online and available to hosts. Similarly, physical storage components can be added, removed, and managed without any need to manage the hosts' view of virtual disks and without taking any data offline.
Numerous implementations for virtualization exist. For example, logical unit number (LUN) masking may be employed to prevent each host from accessing storage resources that it is not permitted to use. In general terms, LUN masking makes particular LUNs available to some hosts, but unavailable to others. LUN masking filters are typically installed as specialty software (e.g., a device driver) on each host. Although this software may be configured from a centralized management application, ultimately, each host is responsible for maintaining a proper configuration for LUN masking.
Other methods for virtualization exist. For example, specialized devices may be used “in-band,” between hosts and storage devices, to provide virtualized storage to the hosts. One example of a fabric enabled for in-band storage virtualization, i.e., routing network traffic from a host 104 to a storage device 120a, 120b via a Fibre Channel switch 107, is shown in FIG. 1B. As shown in FIG. 1B, a host 104 has, among other elements, a host bus adapter (HBA) 106. Conventionally, the HBA 106 is a daughter board connected to the host 104. Each HBA connects a host 104 to other network and storage devices 120a, 120b on the fabric 102 via the Fibre Channel switch 107. As is known in the art, each HBA 106 has a World Wide Name (WWN), which is a unique identifier assigned to each Fibre Channel device. A WWN identifies the HBA 106, and thus the respective host 104, to the Fibre Channel switch 107 and other devices on the fabric 102. The storage devices 120a, 120b also have unique WWNs. On the switch 107 side, each device is connected to a particular port, and is identified by a port identifier (PID). The PID identifies the physical switch and the port to which each network device is attached. As a PID is dependent on the switch, a PID may change in certain situations.
The Fibre Channel switch 107 includes a virtualization processor 108, and a name server 109, which stores information about all devices in the fabric 102. Typically, a name server 109 operates on each Fibre Channel switch in the fabric 102. The virtualization processor 108 creates virtual devices 114, 116 to interface between the host 104 and the physical storage 120a, 120b. Virtualization of SAN devices accelerates replacement of storage devices 120a, 120b and HBAs. SAN devices can be virtualized as initiators or targets to create virtual targets or virtual initiators. The logical units of the virtual target 114 correspond to volumes as defined by the volume manager 112. The first and second virtual logic units 118, 119 map to the physical storage devices 120a, 120b, respectively. The virtual target 114 appears as a normal Fibre Channel Protocol (FCP) device to the host 104. The host 104 discovers the virtual target 114 through a fabric directory service.
Virtualization may best be understood by of describing an example frame intended to pass from the host 104 (i.e., the initiator) to the storage device 120a (the target), using a translation operation (such as data mirroring) to back up the data on the storage device 120b. In this process, the initiator (host 104) issues a command to a virtual target 114, which is located in the switch 107. The virtual target 114, known to the initiator, has a different WWN than the actual target (storage device 120a). The switch 107 then applies storage application logic to perform mirroring. Thus, the command is sent to the storage device 120a, and a copy of the command is sent to the storage device 120b. In addition to mirroring, many data services are available in a fabric 102, including, for example, migration, snapshot, replication, and journaling. These translation services are discussed more fully in U.S. patent application Ser. No. 10/695,408, the contents of which are incorporated by reference. However, the proper execution of such services requires that each device knows all available devices on the SAN. However, adding, removing, or changing a device on a fabric requires the host and the target in a fabric to perform a fabric login and re-learn all devices (i.e., the PIDs and WWNs of the devices) on the fabric.
For example, when a device (e.g., host 104) is connected to the Fibre Channel switch 107, it performs an initialization process known as a fabric login. In this process, the switch 107 registers the WWN of the device with the name server 110, which generates a unique PID for the device. As mentioned above, the PID describes the location of the device in relation to the switch 107 in the SAN with information such as the switch and switch port that the device is connected to. Initialized devices that are initiators attempt to log in to other devices on the SAN to find out what they are and to create proper connections to the devices. This learning is performed by querying the name server 110 in the switch 107 to receive the PID and WWN of each device. Further, when a device connects to or disconnects from a fabric, the switch 107 sends registered state change notifications (RSCNs) to the devices that have registered to receive them.
Conventionally, inserting a virtual target with its own WWN between an existing host and a physical target requires the host to break the existing connection and re-scan to find the new virtual target with its WWN. While this re-scanning is troublesome, and desirable to be removed, a larger problem is that both fabric zoning and access control lists (ACLs) maintained by various entities also have to be changed. Fabric zoning is complicated and being required to change it to allow use of the virtual target is burdensome. Changing the ACLs is even more burdensome as it requires administrator operations on each of the affected devices. Thus, insertion of a virtual target is a burdensome task and alleviating the effect is desirable. Although advances in Fibre Channel standards have helped make these processes less disruptive to a SAN, network designers are continuously seeking new ways to increase storage space, processing capabilities, and data transmission rates, while decreasing “downtime” periods on a fabric 102.